An ERP system 100 may comprise a three tier architecture, as shown in FIG. 1. The ERP system 100 comprises a database server 102, a plurality of application servers (AS) 104a-c and a plurality of user devices or terminals 106a-f. 
An ERP system may, for example, be a Systems, Applications and Products in Data Systems (SAP®) system. Other terms may be encompassed by an ERP system, as used herein, such as an Enterprise Planning Management System, an Enterprise Management System, an Enterprise Software system and an Enterprise Application Software system.
The database server 102 is in data communication with the ASs 104a-c and the ASs 104a-c are in data communication with the user devices 106a-f. FIG. 1 shows only a single database server 102, however there may be multiple database servers 102 in an ERP system. Similarly, FIG. 1 shows a specific number of ASs 104a-c and user devices 106a-f, but this will be understood to be illustrative only and there may be any number of ASs 104a-c and/or user devices 106a-f. 
The user devices 106a-f are configured to display an ERP system front-end to the users enabling them to interact with the ERP system. Typically, the ASs 104a-c are remotely located with respect to the user devices 106a-f. The ASs 104a-c are configured to receive user requests entered via the front-end and to process those requests using application logic, such that they can be passed to the database server 102. The ASs 104a-c are further configured to read data from the database server 102, process that data using application logic and pass the processed data to the user devices 106a-f for presentation to a user. The ASs 104a-c are configured to write data to the database server 102 and/or to read data from the database server 102, which stores data relating to the ERP system. Data communications between the database server 102, the ASs 104a-c and the user devices 106a-f may be over a computer network, such as an internet, intranet or the Internet. Such data communications may be wired, wireless or a combination of both.
When making changes or updates to an ERP system, it is necessary to test those changes or updates before they are implemented on the ERP system. It is noted that an update to an ERP system relates to updates of the operation of the system, such as updates to the system logic and not merely to an update of data held in the database 102. Testing updates to the ERP system reduces the risk of any bugs or errors in the changes or updates corrupting the data stored in the ERP system. As part of that process, different systems can be defined, as shown in FIG. 2. A “development” system 200 may be defined as a system in which software engineers are able to develop new routines and code to implement the changes or updates. Further, a “test” system 202 may be defined as a system in which the developed changes or updates may be tested before being implemented in a “live” (or “production”) system 204, which is the operational ERP system 100. FIG. 2 shows the progression of the changes or updates through the three systems 200, 202, 204 defined.
Each of the development system 200, the test system 202 and the live system 204 may comprise the features of the ERP system 100 shown in FIG. 1. The development system 200 and the test system 202 may be a representation of the live system 204 at a particular time.
The development system 200 will undergo low level testing and debugging by the software engineering team developing the changes or updates to be implemented. The test system 202 may be subjected to a plurality of more detailed user operations that may be undertaken by a specific user or users to determine whether there are any bugs or errors in the changes or updates. This process may involve a number of users devoting a set period of time, such as one or more days, to testing the system. These users are therefore taken away from their normal duties during that time. In addition, testing scenarios are determined so that the users can run through operations in order to test the test system 202, but these inevitably do not represent a full test of the test system, as they only test those operations that a developer of the testing scenarios is able to think of.